Process model repositories and PNML

Bringing system and process models together in repositories facilitates the interchange of model information between modelling tools, and allows the combination and interlinking of complementary models. Petriweb is a web application for managing such repositories. It supports hierarchical process models, represented in a standard format, PNML (the Petri Net Markup Language). Properties can be associated with models, with values supplied manually or by applying tools. This design allows for easy interfacing with tools for modelling and analysis. Petriweb’s first application is a repository for use in research and education that illustrates theoretical properties of Petri nets with examples and counterexamples. To make the creation of examples as easy and flexible as possible, we created Yasper (Yet Another Smart Process EditoR). Yasper combines the benefits of a generic diagram editor with unique features for Petri net editing, and interfaces with Petriweb and other tools through PNML import/export. Petriweb’s design is closely tied to that of PNML; it can provide good support for PNML’s extensibility. PNML is suitable as a mechanism to define document formats for Petri net types, but conflicts between such definitions are still hard to detect; we propose additions to improve this situation. 1 Model repositories for knowledge sharing Many techniques and tools exist for modelling static and dynamic aspects of business processes and systems, all with their own features and benefits. Therefore, interoperability between tools is often a major concern. It may be necessary to transfer models from one tool to another; for example, if the second tool has different capabilities, runs on a different platform, is more convenient to use or less expensive. This is addressed by standard document formats, such as GXL [15], XMI [13], BPEL [11], XPDL [30], and PNML [12]. They define which information can be exchanged between tools, and provide a standard syntax to express it. The ideal is depicted in figure 1: tools that read and write the same document format. However, this does not guarantee full interoperability. Constraints on how elements can be combined and the intended interpretation of the syntax are often described informally, if at all; this may leave tool A (e.g. a Petri net editor) the standard document format that tools read and write tool B (e.g. a workflow modelling tool) tool D (e.g. a document converter) some input format tool E (e.g. a process model database) some output format tool C (e.g. a Petri net analyser) Figure 1: Using a standard document interchange format. tool A models written by tool A models read by tool A tool B models read by tool B models written by tool B the extensible document format Figure 2: Using an extensible standard format. the specification ambiguous or incomplete in subtle ways. Problems can be found even when tools completely comply with the document format’s specification; in such cases, the specification or the document format itself must be updated, which in turn may require updates to all documents and processing tools. Therefore, standards must undergo careful change management. To complicate the issue further, two tools may support a common technique with different specific extensions. Extensible document formats allow these to be defined as separate, extended document formats. The situation is illustrated in figure 2: each tool can read only a specific set of models, and usually writes an even further restricted subset, but tools can still interchange models, even when they do not that support the exact same set of extensions. If the extensions are not in conflict, a tool can simply proceed to ignore the extensions it does not understand; but this will not always produce meaningful results. the PNML document format. An example of such an extensible document format is PNML, the Petri Net Markup Language [12]; it was designed for Petri nets [22], but is also suited for related modelling techniques. A particular type of Petri net – a particular combination of syntactic features – is defined by a Petri Net Type Definition (PNTD). Although it is still under development, PNML is already supported by some tools. A common interchange format can serve as a simple design contract to discipline the development of new tools. This is especially important when multiple small tools are written to complement existing tools or each other. However, while well-defined exchange formats are required to make tools interoperable, they are not sufficient. Another important step is to create repositories of models ([16], [20], [14], . . . ) in which models can be shared, for instance with a publish-and-subscribe mechanism. Such repositories can serve to provide practical support for a document format, by providing example models, syntax validation services, etc. Tools that support the document format can be interfaced with the repository. Moreover, repositories can be used to combine and integrate different types of models, that cannot be described with a common document format. In many situations, we require combinations of models of different types to describe a system: for instance, workflow models, organization models and data models. It is not wise to try and cover all this different information with a single document format; there are too many different types of models to consider. However, by combining such models in a repository, we can express relationships between them. For instance, if a Petri net expresses a workflow, its transitions are tasks to be executed by members of the organization, while the data involved appear in a business data model. Whereas an exchange format defines a greatest common divisor between models of different tools, combining them in a repository offers a least common multiple. The use of repositories allows a less tool-oriented, more model-centric approach to modelling. Instead of relying on a single tool to do everything, various smaller tools can be used for what they do best. We are creating such repositories, focusing on process models, for the following two application areas: • Petriweb, a database of Petri nets for use in research and education • enterprise modelling with combinations of models The first application uses a repository to support collections of similar models, namely, Petri nets and related process models, expressed in PNML. In the second application, we combine and interrelate such process models with other types of models. This ongoing work is not discussed in the present paper. 2 Petriweb: Petri net repository management The Petriweb application [1] is a web front end to a database with Petri nets. Its purpose is to collect example Petri nets used to illustrate Petri net theory: standard examples, modelling exercises, examples and counterexamples used in proofs. The goal is to advance on the present state of affairs, in which researchers and educators use the first diagram drawing tool or Petri net tool that comes to hand to draw the same illustrations of the same basic material, and reuse very little. Creating good illustrations can be a lot of work. Petriweb aims to develop a repository in which finding a suitable Petri net is less work than creating one from scratch with an ad hoc tool. Privileged users can upload new PNML documents to the database; an administrator must approve them to make them publicly viewable. Petriweb mainly contains small, flat, uncolored Petri nets, but it supports hierarchy and allows additional properties to be attached to Petri net elements. All nets are imported and exported in PNML format; basic compatibility with other tools that support PNML, such as the Petri Net Kernel [19], is verified from time to time. Petriweb can even smoothen out incompatibilities between existing PNML variants – see section 2.2. The static view on Petri nets is not enough. Often, a Petri net must be shown with one or more specific firing sequences. Petriweb delegates the task of generating firing sequences to external tools, but they can be imported into Petriweb in a custom-designed XML format. Firing sequences can be replayed in the built-in browser (figure 5); they can also be employed in certain types of analysis, e.g. process mining [28]. 2.1 Properties The main challenge for Petriweb is the search function. It is obvious how to model a two-place buffer, and somewhat predictable how to model a petrol station, but it is not at all clear how to find such models in a collection of Petri nets. No general assumption can be made on what properties a user would like to use as a basis for search. Therefore, the Petriweb software leaves the definition of properties open. Arbitrary properties can be attached to Petri nets. They are typed: Boolean, enumerated, integer or string, or a file format. Handassigned properties must be filled in by a user when a document is uploaded or approved; nothing Figure 3: Petriweb: specifying a search Figure 4: Petriweb: browsing search results in the system checks that they make any sense. Computed properties have code associated with them that computes a value automatically from PNML. An administrator can delete, add, redefine, and recompute any property. Properties marked as searchable appear on the Petriweb search form (figure 3). Search results are shown with all their properties, including a diagram sketch (figure 4). The diagram sketch hyperlinks to a full diagram viewer (figure 5), which visualises the Petri net, including hierarchy. Another hyperlink provides the PNML representation. Most of the properties that users would like to define and use in Petriweb apply to the individual Petri nets and subnets within a PNML document. Therefore, search results are not always whole documents, and properties shown with results or shown in the search form must be attached to nets and subnets. This is true for structural and behavioral properties of a theoretical nature, but just as Figure 5: Petriweb: browsing the diagram of a result Figure 6: Petriweb: defining a property well for non-inherent, manually assigned properties, such as a net’s stated purpose (”petrol station”) or its original author and publication (”Smith & Jones 1984, p. 18”). In order to support this, Petriweb must break down uploaded PNML documents into the smallest constituents for which such properties can be defined. In fact it completely parses the documents and represents the structure of their constituent elements explicitly in the database table structure. This makes the PNML completely regenerable from the database, and allows properties to be associated with literally any element within a net. This means that a property is, in effect, what in PNML parlance is known as a PNML label: a syntactic construct added to a PNML element type (net, place, page, transition or arc). Although the present version of Petriweb does not support this yet, PNML labels within uploaded PNML documents can be shown as properties in Petriweb, while properties defined within Petriweb can be included as PNML labels into exported PNML. Thus, Petriweb can serve as a tool for defining PNML labels. A corresponding PNTD can be generated automatically. 2.2 Computed properties When a property is defined, a program can be associated with it to compute its value. To this end the definer provides either a command line to invoke the program in question, or the text of an XSLT [9] stylesheet. Simple structural properties, such as the number of tokens, whether a net is connected, or whether it is free-choice, are typically defined with XSLT. Such properties are essential in narrowing searches. More complex, behavioral properties, such as the soundness of workflow nets ([3], [18]) can be computed with specialized external tools, which operate as filters that take a PNML document and yield one or more property values. In this way, intelligent Petri net processing is incorporated on the server side. Computed properties can also be used to transform Petri nets into alternative formats. This is most useful when the user has applications installed locally that display or process models in such formats. Useful types of transformations include conversions to a different form of PNML: for instance, a computed property can flatten structured nets, for the benefit of tools that only accept flat (basic) PNML; another application is to adapt PNML for tools that do not comply with the present PNML standard, such as the Petri Net Kernel and some of our own utilities; completely different representations of process models: most process modelling and analysis tools have non-PNML native file formats; if a conversion program exists, it can be incorporated as a computed property; visualizations: e.g. in a vector graphics format such as SVG [25] The screenshots in figure 3 and figure 4 show the use of computed properties to integrate Woflan [4], a workflow analysis tool. The woflan property provides client-side integration: clicking on its value produces a file in native Woflan input, and will feed it to the Woflan application if the user has it installed. Properties such as workflow, live and bounded are the result of server-side integration : their values are computed by a script that invokes the Woflan web service, and the results are stored in Petriweb. 2.3 The range of supported Petri nets Petri nets feature prominently in our undergraduate computer science curriculum. They are used in courses, student projects, and research. Over time, many users create many Petri nets, and mostly throw them away after one-time use. Petriweb provides the means to collect these efforts and make them available for reuse, where appropriate. Complex models are created with modelling tools such as the Petri Net Kernel [19], CPN Tools [23] — which support PNML — ExSpect [5], Arena [24], or Protos [21] – which do not. Computed properties (cf. section 2.2) provide a simple mechanism for integration; work to actually interface with some of these tools is in progress. Our first concern, however, was to support the reuse of relatively simple nets, used as illustrations in course materials, student exercises and research papers. Such nets are often drawn with generalpurpose drawing packages. They have uncolored tokens, and appear on a single page, sometimes with a marking. They often exhibit hierarchy in the form of ”inline subnets”, indicated by a named rectangle surrounding part of the net. Inline subnets always act as transitions, in the sense that their cross-border arcs always connect transitions on the inside with places on the outside. They are used often enough to require support by Petriweb and supporting tools. Modelling tools such as ExSpect [5] and ProVision Workflow Modeller [26] display the contents of subnets on separate pages, as shown in figure 7. The connections and the places they connect to appear twice, once in the context net and once in the subnet. Every place in the context must have a separate reference in the subnet content, while multiple references in a subnet can be made to the same context place. Therefore, the appearances of context places within a subnet are, in effect, references to those places. These places are called the subnet’s pins, and they constitute the subnet’s interface. dining philosophers fork0